fix width calculation for draw.aacircle()#3699
fix width calculation for draw.aacircle()#3699Fantastair wants to merge 2 commits intopygame-community:mainfrom
draw.aacircle()#3699Conversation
📝 WalkthroughWalkthroughModified circle drawing calls in Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Important Action Needed: IP Allowlist UpdateIf your organization protects your Git platform with IP whitelisting, please add the new CodeRabbit IP address to your allowlist:
Failure to add the new IP will result in interrupted reviews. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
As for why I ultimately chose to modify the parameter passing on the calling side rather than the underlying implementation, it's because Additionally, I added an explanatory comment inside the ‘draw_circle_xiaolinwu()’ function to serve as a reminder for future developers. |
| /* The final drawn thickness will be 1 pixel greater than the value of the | ||
| * “thickness” parameter, as the iteration is performed over a closed | ||
| * interval. */ | ||
| for (int layer_radius = radius - thickness; layer_radius <= radius; |
There was a problem hiding this comment.
I wonder if it would be better to just fix the logic here instead, maybe we should do a radius - thickness + 1 initialization?
EDIT: Just saw your comment about centre of solid circles, but I'm still not convinced. This function should ideally do the "right thing" and the centre special case could be handled separately? I need to do a bit more testing though to understand things in more detail.
There was a problem hiding this comment.
Okay I played around a bit with this, and now I have a clearer understanding.
Basically the main issue is that draw.aacircle always draws an extra pixel at the centre, so a 1 radius circle needs a 3x3 box, a 2 radius circle needs a 5x5 box and so on (yes, just like #1487). So there's always going to be a jump somewhere and this PR is just shifting that jump from 1 -> 3 to (r - 2) -> r. I personally think this is a reasonable compromise given the status quo.
2 participants
For more details, please refer to the discussion in #3682 .